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ABSTRACT 


The  build  cycle  of  a  first  in  class  combat  ship  takes  about  six  years. 
During  that  timeframe  systems  are  being  designed,  installed  and  tested,  but  until 
the  ship  is  in  the  water  and  tested  at  sea  trials  it  is  not  known  if  the  ship  is  fully 
integrated  and  will  actually  perform  as  it  is  designed  to  do.  As  time  progresses 
integration  problems  become  harder  and  more  expensive  to  solve.  Every  time  a 
new  system  is  added  or  upgraded  there  may  be  interference  from  another 
system  that  was  not  anticipated.  It  is  important  to  test  and  verify  each  system  but 
there  is  limited  time  and  resources  to  do  so.  By  successfully  planning  and 
performing  systems  integration  at  the  correct  time  of  the  acquisition  cycle  it  is 
possible  to  reduce  the  chance  of  system  failure.  The  objective  of  this  thesis  is  to 
explain  and  establish  the  process  of  building  a  fully  integrated  combat  ship. 

To  understand  how  to  perform  integration  first  we  must  define  what  it 
means  to  our  customer,  the  Navy,  and  us,  the  shipbuilder.  This  is  accomplished 
in  the  first  chapter.  The  second  chapter  concentrates  on  why  we  need  to  perform 
system  integration  by  explaining  the  history  of  the  U.S.  Navy’s  shipbuilding 
program  and  case  studies  of  successful  and  not  as  successful  integrated 
systems.  The  last  chapter  contains  a  list  of  concepts  and  ideas  to  implement  into 
a  combat  ship  design  and  build  program  to  simplify  shipbuilding  integration. 
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I.  INTEGRATION  CHARACTERIZATION 


A.  INTRODUCTION 

Ships  are  essentially  floating  cities,  and  combat  ships  add  the  complexity 
of  war  fighting  capabilities  to  their  mission.  Of  all  the  equipment  Congress 
purchases  for  the  military,  only  ships  are  in  the  category  of  Capital  equipment. 
This  means  that  the  equipment  has  a  large  dollar  value  and  therefore  special 
oversight.  Shipbuilding  continues  to  be  a  very  labor-intensive  industry  that  relies 
mainly  on  past  performance  and  experience  to  measure  progress  to  completion. 
As  our  systems  become  even  more  complex,  the  old  “rules  of  thumb”  for 
designing  and  building  a  successful  working  ship  may  not  apply. 

The  build  cycle  of  a  first  in  class  combat  ship  takes  about  six  years. 
During  that  timeframe,  systems  are  being  designed,  installed,  and  tested,  but 
until  the  ship  is  in  the  water  and  tested  at  sea  trials  it  is  not  known  if  the  ship  is 
fully  integrated  and  will  actually  perform  as  designed.  As  time  progresses 
integration  problems  become  harder  and  more  expensive  to  solve.  Every  time  a 
new  system  is  added  or  upgraded  there  may  be  interference  from  another 
system  that  was  not  anticipated.  It  is  important  to  test  and  verify  each  system, 
but  there  is  limited  time  and  resources  to  do  so.  By  successfully  planning  and 
performing  systems  integration  at  the  correct  time  of  the  acquisition  cycle,  it  is 
possible  to  reduce  the  chance  of  system  failure.  The  objective  of  this  thesis  is  to 
explain  and  establish  the  process  of  building  a  fully  integrated  combat  ship. 

To  understand  how  to  perform  integration,  first  we  must  define  what  it 
means  to  our  customer,  the  Navy,  and  us,  the  shipbuilder.  This  is  accomplished 
in  the  first  chapter.  The  second  chapter  concentrates  on  why  we  need  to  perform 
system  integration  by  explaining  the  history  of  the  U.S.  Navy’s  shipbuilding 
program  and  case  studies  of  successful  and  not  as  successful  integrated 
systems.  The  last  chapter  contains  concepts  and  ideas  to  implement  into  a 
combat  ship  design  and  build  program  to  simplify  shipbuilding  integration. 
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To  properly  place  systems  integration  into  the  acquisition  cycle,  the  thesis 
begins  with  defining  systems  engineering. 


B.  DEFINING  SYSTEMS  ENGINEERING 

Systems  engineering  is  not  a  field  that  is  as  clear  cut  as  many  of  the  other 
engineering  disciplines,  but  systems  engineering  is  rather  young  compared  to 
traditional  engineering  disciplines,  such  as  civil,  mechanical,  and  electrical 
engineering.  It  may  be  due  to  its  age  that  it’s  hard  to  define  systems 
engineering,  but  defining  of  a  field  of  study  that  does  not  have  any  real  tangible 
product  will  always  be  hard  to  explain  to  people,  especially  engineers.  First,  the 
paper  will  discuss  the  International  Council  on  Systems  Engineering’s  definition 
and  then  the  Department  of  Defense’s  definition,  and  then  compare  the  two 
explanations. 

1.  International  Council  on  Systems  Engineering  Definition 

The  International  Council  on  Systems  Engineering  has  worked  for  years  to 
create  a  concise  definition  of  systems  engineering.  Founded  in  1990,  the 
“International  Council  on  Systems  Engineering  is  an  international  authoritative 
body  promoting  the  application  of  an  interdisciplinary  approach  and  means  to 
enable  the  realization  of  successful  systems.”  (“A  Consensus  of  the  INCOSE 
Fellows,”  2004)  I  find  their  definition  to  be  very  exact  and  understandable: 

Systems  Engineering  is  an  interdisciplinary  approach  and  means  to 
enable  the  realization  of  successful  systems.  It  focuses  on  defining 
customer  needs  and  required  functionality  early  in  the  development 
cycle,  documenting  requirements,  then  proceeding  with  design 
synthesis  and  system  validation  while  considering  the  complete 
problem: 

Operations 

Performance 

Test 

Manufacturing 
Cost  and  Schedule 
Training  and  Support 

Disposal 
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Systems  Engineering  integrates  all  the  disciplines  and  specialty 
groups  into  a  team  effort  forming  a  structured  development  process 
that  proceeds  from  concept  to  production  to  operation.  Systems 
Engineering  considers  both  the  business  and  the  technical  needs  of 
all  customers  with  the  goal  of  providing  a  quality  product  that  meets 
the  user  needs.  (INCOSE  website,  2005) 

By  taking  the  definition  and  decomposing  it  we  can  see  where  integration 
fits  into  the  systems  engineering  definition. 

Systems  Engineering  is  an  interdisciplinary  approach  and  means  to 
enable  the  realization  of  successful  systems.  (INCOSE  website, 

2005) 

This  is  the  overall  goal  of  systems  engineering:  to  create  a  successful 
system;  not  just  a  system,  but  a  successful  one.  That  means  looking  and 
analyzing  the  customer’s  needs  and  requirements  and  ensuring  that  what  the 
customer  is  asking  for  actually  fits  their  needs.  They  could  have  stopped  here, 
but  then  the  definition  would  not  have  told  us  what  systems  engineers  do. 

It  focuses  on  defining  customer  needs  and  required  functionality 
early  in  the  development  cycle,  documenting  requirements,  then 
proceeding  with  design  synthesis  and  system  validation  while 
considering  the  complete  problem: 

Operations 

Performance 

Test 

Manufacturing 
Cost  and  Schedule 
Training  and  Support 
Disposal  (INCOSE  website,  2005) 

The  first  part  of  the  sentence  explains  how  systems  engineers  take  the 
customer  requirements  and  break  them  into  groups  so  that  design  engineers  can 
design  their  part  of  the  system.  With  the  increasing  complexity  of  system  design, 
boundaries  must  be  drawn  for  the  work  to  be  performed  correctly.  When  the 
systems  engineer  breaks  the  system  down  into  these  workable  chunks  they  pass 
along  to  the  design  engineer  how  the  seven  items  listed  need  to  be  considered  in 
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the  design.  By  doing  this  the  design  engineers  can  focus  on  their  part  of  the 
problem  and  are  not  distracted  by  other  parts  of  the  problem.  Requirements 
keep  designers  focused  on  the  problem  they  have  been  given  responsibility  to 
solve. 


Systems  Engineering  integrates  all  the  disciplines  and  specialty 
groups  into  a  team  effort  forming  a  structured  development  process 
that  proceeds  from  concept  to  production  to  operation.  (INCOSE 
website,  2005) 

This  part  of  the  definition  concentrates  on  integration.  It  is  this  part  of  the 
definition  on  which  this  thesis  is  focused.  Once  the  system  has  been 
decomposed  for  design  purposes  to  obtain  a  buildable  and  usable  system  it  must 
be  merged  back  together.  This  is  the  integration  phase  of  the  design  process. 

Systems  Engineering  considers  both  the  business  and  the  technical 
needs  of  all  customers  with  the  goal  of  providing  a  quality  product 
that  meets  the  user  needs.  (INCOSE  website,  2005) 

The  last  sentence  is  a  wrap  up  of  what  was  said  in  the  first  sentence, 
making  note  that  systems  engineering  focuses  on  business  and  technical  needs. 
The  systems  engineers  are  responsible  for  making  certain  that  the  customer 
receives  what  they  need  and  can  afford. 

2.  Department  of  Defense  Definition 

Because  this  paper  is  focused  on  building  U.S.  Navy  ships  we  will  explore 
the  definition  the  Department  of  Defense  has  for  systems  engineering.  It  should 
be  noted  that  the  Department  of  Defense  definition  is  created  not  for  the  builder 
of  system,  but  the  program  managers  and  defense  employees  acquiring  the 
system.  From  the  Defense  Acquisition  Guidebook  (2005): 

Systems  engineering  is  the  overarching  process  that  a  program 
team  applies  to  transition  from  a  stated  capability  need  to  an 
operationally  effective  and  suitable  system.  Systems  engineering 
encompasses  the  application  of  systems  engineering  processes 
across  the  acquisition  life  cycle  (adapted  to  each  and  every  phase) 
and  is  intended  to  be  the  integrating  mechanism  for  balanced 
solutions  addressing  capability  needs,  design  considerations  and 
constraints,  as  well  as  limitations  imposed  by  technology,  budget, 
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and  schedule.  The  systems  engineering  processes  are  applied 
early  in  concept  definition,  and  then  continuously  throughout  the 
total  life  cycle.  (Chap.  4.0) 

As  done  previously  with  the  International  Council  on  Systems  Engineering 
definition,  we  will  separate  and  analyze  the  definition.  The  first  sentence: 

Systems  engineering  is  the  overarching  process  that  a  program 
team  applies  to  transition  from  a  stated  capability  need  to  an 
operationally  effective  and  suitable  system.  (Defense  Acquisition 
Guidebook,  2005,  Chap.  4.0) 

What  is  being  described  is  that  a  process  is  used  to  get  from  customer 
needs  to  a  workable  system.  It’s  said  in  a  different  way,  but  the  International 
Council  on  Systems  Engineering  definition  covers  this  point.  There  is  not  the 
emphasis  on  providing  the  customer  with  what  they  need  versus  what  they  ask 
for  with  this  definition.  It  is  assumed  that  the  “stated  capability”  has  already  been 
judged  as  achievable  by  the  government. 

Systems  engineering  encompasses  the  application  of  systems 
engineering  processes  across  the  acquisition  life  cycle  (adapted  to 
each  and  every  phase)  and  is  intended  to  be  the  integrating 
mechanism  for  balanced  solutions  addressing  capability  needs, 
design  considerations  and  constraints,  as  well  as  limitations 
imposed  by  technology,  budget,  and  schedule.  (Defense 
Acquisition  Guidebook,  2005,  Chap.  4.0) 

Here  is  the  point  where  integrating  is  mentioned  in  the  definition. 
Department  of  Defense  has  a  shorter  list  than  the  International  Council  on 
Systems  Engineering,  leaving  out  manufacturing,  test,  disposal,  etc  but 
essentially  says  that  systems  engineering  should  be  used  through  out  the  entire 
acquisition  life  cycle  which  one  could  say  includes  those  items  left  out  of  the 
Department  of  Defense  definition.  The  Department  of  Defense  states  that 
systems  engineering  is  the  “mechanism”  for  how  the  parts  are  integrated  for  the 
overall  system.  This  implies  that  systems  integration  is  a  part  of  systems 
engineering  process  and  therefore  not  at  the  same  level. 

And  then  the  last  sentence:  “The  systems  engineering  processes  are 
applied  early  in  concept  definition,  and  then  continuously  throughout  the  total  life 
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cycle,”  (Defense  Acquisition  Guidebook,  2005,  Chap.  4.0)  reemphasizing  that 
systems  engineering  is  to  be  used  throughout  the  entire  acquisition  cycle. 

3.  Key  Points  of  Systems  Engineering  Definitions 

I  chose  to  use  two  definitions  for  explaining  systems  engineering:  the 
International  Council  on  Systems  Engineering  definition  because  it  is  a  very 
concise  yet  broad  definition  that  concentrates  on  the  system  engineer  designing 
and  building  the  system,  and  the  Department  of  Defense  definition  because  the 
customer  of  United  States  Navy  warships  is  the  Department  of  Defense. 

Table  1  summarizes  the  key  points  each  definition  makes  about  a  three 
main  topics. 


KEY  POINT 

INTERNATIONAL  COUNCIL 

ON  SYSTEMS  ENGINEERING 

DEPARTMENT  OF 

DEFENSE 

Goal  of  SE 

Create  a  successful  system  that 

meets  technical  and  business 

customer  needs. 

Create  an  operationally 

effective  and  suitable  system. 

Timeframe 

Concept  to  operation. 

Throughout  the  entire 

acquisition  cycle. 

How  System 

Integration  is 

Addressed 

Brings  together  people  with 

different  specialties. 

Described  as  the  “balancing 

mechanism.” 

Table  1 :  Key  Points  of  Systems  Engineering  Definition  (after  INCOSE 

website,  2005  and  Defense  Acquisition  Guidebook,  2005,  Chap.  4.0) 


The  International  Council  on  Systems  Engineering  has  a  broader  focus  on 
commercial  applications,  while  the  Department  of  Defense  centers  on  products 
used  by  the  military.  For  this  reason  the  goals  are  different.  The  International 
Council  on  Systems  Engineering’s  goal  is  to  create  a  successful  system,  while 
the  Department  of  Defense  wants  a  system  that  is  effective  and  suitable  in  the 
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environment  it  was  created  to  fight  in.  In  the  commercial  world  success  is 
measured  by  profits,  but  in  the  Department  of  Defense  world  success  is 
measured  in  the  ability  to  save  our  soldier’s  lives  and  protect  our  country. 

The  timeframe  is  longer  for  the  Department  of  Defense  to  include  the 
disposal  cycle  because  lifecycle  issues  are  generally  not  as  important  in 
commercial  applications  as  they  are  with  the  Department  of  Defense.  Ships  are 
normally  kept  in  service  for  thirty  years.  Trying  to  lower  the  costs  associated  with 
operating  ships  is  very  important  to  the  United  States  Navy. 

Systems  Integration  is  mentioned  in  both  definitions,  but  with  different 
explanations.  The  International  Council  on  Systems  Engineering  concentrates 
more  on  the  idea  of  bringing  together  different  ideas  and  backgrounds  to  create  a 
product.  The  International  Council  on  Systems  Engineering  centers  on  a  people 
oriented  tasks.  The  Department  of  Defense  uses  integrating  to  mean  how  the 
product  is  balanced  across  cost,  schedule,  and  performance.  The  definitions 
want  the  same  outcome,  but  the  Department  of  Defense  centers  on  the  program 
metrics  of  cost,  schedule,  and  performance.  Those  items  are  important  in  the 
commercial  world  too,  but  those  are  constraints  commercial  firms  always  have  to 
consider.  The  Department  of  Defense  has  been  evolving  from  a  time  where  the 
most  important  consideration  was  performance,  then  schedule,  and  cost  was  the 
least  important.  Now  the  Department  of  Defense  faces  more  public  scrutiny  on 
how  the  defense  budget  is  spent  and  must  change  the  way  their  systems  are 
procured.  This  is  the  reason  for  the  different  emphasizes  in  the  definitions 
between  the  International  Council  on  Systems  Engineering  and  the  Department 
of  Defense. 

4.  Author’s  Synopsis  of  Systems  Engineering  Definition 

My  personal  explanation  and  purpose  of  systems  engineering  is  “to  bring 
order  to  chaos.”  We  have  reached  a  period  of  time  where  products  or  systems 
are  so  complex  that  a  small  group  of  designers  can  no  longer  understand  every 
part  of  the  system.  When  the  ability  to  understand  every  detail  and  make  it 
whole  with  a  manageable  group  of  people  was  lost,  systems  engineering  as  a 
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separate  field  of  practice  became  necessary.  For  this  reason  it  is  my  belief  that  it 
is  not  a  question  of  whether  systems  engineering  exists  or  not,  but  if  it  is  good  or 
bad  systems  engineering. 

Systems  engineering  should  not  necessarily  deliver  to  the  customer  what 
they  initially  request.  There  is  an  important  distinction  here  in  that  just  because 
the  customer  says  they  want  a  certain  feature  that  feature  may  not  be  needed  to 
achieve  the  overall  goal  of  the  system  or  it  could  be  unrealistic  for  the  amount  of 
money  and  time  that  it  would  take  the  contractor  to  develop.  It  is  the  systems 
engineer’s  responsibility  to  educate  the  customer  on  these  issues. 


C.  DEFINING  SYSTEMS  INTEGRATION 

Systems  engineering  is  the  process  that  creates  an  environment  in  which 
the  system  can  be  designed.  It  provides  the  clear  path  forward  to  each  design 
engineer.  Systems  integration  is  the  part  of  that  process  that  brings  back 
together  what  has  been  separated  out  for  design  purposes.  First  the  paper  will 
discuss  the  Department  of  Defense’s  definition  of  systems  integration  and  then 
explain  what  it  means  to  the  shipbuilder. 

1.  Department  of  Defense’s  Definition  of  Systems  Integration 

Systems  integration  is  a  part  of  systems  engineering  and  systems 
engineering  by  Department  of  Defense  rules  is  suppose  to  occur  throughout  the 
entire  acquisition  cycle.  The  Department  of  Defense  places  integration  in  the  Life 
Cycle  Management  Framework  in  Figure  1  as  the  first  part  of  the  System 
Development  and  Demonstration  Phase  located  between  Milestone  B  and  C. 
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Figure  1 .  Integrated  Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management  Framework  (from 

http://akss.dau.mil/dapc/index.html) 
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See  Figure  2  for  a  simpler  view  of  the  phases  and  milestones.  The  figure 
is  from  2003,  but  the  phases  have  remained  the  same.  This  phase  was  added  in 
October  2000.  (Dillard,  2003,  p.  33)  In  that  phase  are  two  sub  phases,  System 
Integration  and  System  Demonstration. 


The  Current  2003  Model 


Program 

Initiation 


DoDI  5000.2  of  May  2003 


Technology 
Opportunities 
&  User  Needs  ^ 

Concept 

Refinement 

Technology 

Development 

System  Development  & 
Demonstration 

Production  &  Deployment 

Operations 

and 

Support 

System  k 

Integration  { 

V  System 

)  Demonstration 

r 

Production  y 
Readiness,  \ 
LRIP  &  IOT&E  > 

\  Full  Rate 
)  Production  & 
Deplo  yment 

1 

f  1 

r  i 

1  11  1  ■ 

r  y 

r 

Figure  2.  Simplified  Defense  Acquisition  Management  Framework  (from 

Dillard,  2003,  p.  36) 


System  Integration  falls  between  Milestone  B  and  Design  Readiness 
Review  (DRR).  Milestone  B  marks  the  end  of  the  Technology  Development 
Phase.  “The  Technology  Development  Phase  ends  when  the  Milestone  Decision 
Authority  determines  that  technologies  are  sufficiently  mature.  This 
determination,  along  with  the  satisfaction  of  other  statutory  and  regulatory 
requirements,  supports  program  initiation.”  (Defense  Acquisition  Guidebook, 
2005,  Chap.  2.2.1)  This  tells  us  that  the  concept  design  must  be  mature  enough 
to  proceed  to  being  the  System  Integration  sub  phase.  It  is  important  to  note 
here  that  what  the  Department  of  Defense  considers  as  integration  is  not  the 
same  thing  that  the  builder  of  the  system  would  call  integration.  This  statement 
will  be  expounded  in  Section  3,  author’s  synopsis  of  systems  integration 
definition. 
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Figure  3  displays  the  model  used  by  Department  of  Defense  to  display  the 
tasks  required  for  the  phase.  System  Integration  is  the  downward  part  of  the  “v” 
and  System  Demonstration  is  the  upward  part  of  the  “v.” 
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Figure  3.  Department  of  Defense  SDD  Model  (from  Defense  Acquisition 

Guidebook,  2005,  Chap.  4. 3. 3. 3) 


To  finish  the  System  Integration  sub  phase  is  the  DRR  event.  From  the 
Defense  Acquisition  Guidebook: 

The  Design  Readiness  Review  during  SDD  provides  an  opportunity 
for  mid-phase  assessment  of  design  maturity  as  evidenced  by 
measures  such  as  the  number  of  subsystem  and  system  design 
reviews  successfully  completed;  the  percentage  of  drawings 
completed;  planned  corrective  actions  to  hardware/software 
deficiencies;  adequate  development  testing;  an  assessment  of 
environment,  safety  and  occupational  health  risks;  a  completed 
failure  modes  and  effects  analysis;  the  identification  of  key  system 
characteristics  and  critical  manufacturing  processes;  an  estimate  of 
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system  reliability  based  on  demonstrated  reliability  rates;  etc. 
Successful  completion  of  the  Design  Readiness  Review  ends 
System  Integration  and  continues  the  SDD  phase  into  the  System 
Demonstration  effort.  MDAs  may,  consistent  with  the  intent  of  this 
paragraph,  determine  the  form  and  content  of  the  review.  (Defense 
Acquisition  Guidebook,  2005,  Chap.  3.7.4) 

This  means  that  before  the  system  integration  sub  phase  the  concept 
design  should  be  mature,  but  production  does  not  begin  until  after  the  system 
integration  sub  phase.  This  places  system  integration  for  the  Department  of 
Defense  between  requirements  development  and  production. 

2.  Systems  Integration  Sub  Phase 

In  the  Technology  Development  Phase  the  design  engineers  have  taken 
their  requirements  provided  by  the  system  engineers  and  designed  a  product  that 
meets  those  requirements.  But  in  the  System  Integration  sub  phase  the 
engineers  gather  together  and  review  with  each  other  various  parts  of  the  design. 
Dillard  (2003)  defines  the  task  of  the  system  integration  phase  “for  the  reduction 
of  integration  risk.  The  architecture  is  complete,  now  system  integration  is 
applied  to  demonstrated  subsystems  and  components.”  (p.  33)  The  Defense 
Acquisition  Guidebook  (2005)  describes  the  Systems  Integration  phase  as 
follows: 

The  System  Integration  work  effort  begins  when  the  program 
manager  has  a  technical  solution  for  the  system  or  increment  of 
capability,  but  has  not  integrated  the  components  and  subsystems 
into  a  system.  Through  the  use  of  systems  engineering,  the 
System  Integration  effort  integrates  components  and  subsystems, 
completes  the  detailed  design,  and  reduces  system  level  risk.  The 
effort  typically  includes  the  demonstration  of  prototype  articles  or 
engineering  development  models.  (Chap.  4. 3. 3. 2) 

The  easiest  way  to  explain  this  is  to  take  an  example. 

A  combat  ship  for  the  U.S.  Navy  has  a  performance  requirement  to  have  a 
maximum  ship  speed  of  30  knots.  First  the  system  engineer  splits  and  assigns 
the  requirement  to  the  naval  architects,  the  power  engineers,  and  control 
engineers  if  they  expect  to  use  software  to  control  the  equipment.  The  naval 
architects  create  a  hull  form  that  is  capable  of  reaching  30  knots,  the  power 
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engineers  size  the  engine  to  provide  enough  power  to  go  30  knots,  and  the 
control  engineers  write  software  to  manage  the  associated  equipment.  See 
Figure  4  for  the  decomposition  of  the  requirement.  Each  sub-box  represents  a 
group  of  engineers  performing  their  part  of  the  requirement.  The  split  of  work  is 
divided  and  each  group  of  engineers  is  responsible  for  meeting  their  part  of  the 
requirement.  This  is  the  point  where  systems  integration  gets  started. 


Figure  4.  Example  Requirement  Decomposition 

Does  the  engine  the  power  engineers  chose  fit  in  the  hull  form  the  naval 
architects  designed?  Can  production  install  it?  Will  the  combination  of  the  hull 
form  and  engine  be  structurally  sound?  Can  the  control  system  support  going  30 
knots  within  given  safety  parameters?  None  of  these  issues  have  been 
addressed  at  this  stage.  These  and  lots  of  other  questions  are  addressed  in  the 
system  integration  sub  phase  when  creating  the  design  and  build  specifications. 
It  is  here  that  the  constraints  each  engineering  group  put  on  the  other  groups  is 
documented.  For  this  reason  the  Department  of  Defense  calls  this  sub  phase 
“System  Integration.” 

In  Figure  5  you  see  the  model  from  the  left  hand  side  or  Integration  part  of 
the  SDD  Phase.  Now  we  will  analyze  each  box  separately.  Note  that  every 
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program  under  the  Department  of  Defense  does  not  follow  these  steps  entirely 
and  deviation  to  the  process  as  deemed  necessary  by  the  Program  Office  is 
acceptable. 


INPUTS 


Figure  5.  DoD  Integration  Model  (after  Lifecycle  Model) 


a.  Inputs 

At  the  completion  of  Milestone  B  you  should  have  the  documents 
listed  below.  The  maturity  of  these  documents  directly  affects  the  maturity  of  the 
system  design. 

•  System  Performance  Specs 
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•  Exit  Criteria 

•  Validated  System  Support  and  Maintenance  Objectives  and 

Requirements 

•  Acquisition  Program  Baseline  (APB) 

•  Capability  Development  Document  (CDD) 

•  Systems  Engineering  Plan  (SEP) 

•  Information  Support  Plan  (ISP) 

•  Test  and  Evaluation  Master  Plan  (TEMP) 

•  Product  Support  Strategy  (Defense  Acquisition  Guidebook,  2005, 

Chap.  4.3.3.1) 

b.  Refine  System  Performance 

From  the  inputs  you  refine  the  system  performance.  The  user 
needs  are  updated  and  finalized  as  Key  Performance  Parameters  in  the 
Capability  Development  Document.  Key  Performance  Parameters  can  be 
changed  after  this  phase,  but  such  change  requires  approval  authority.  The 
design  needs  to  be  relatively  stable  at  this  point  to  keep  costs  under  control.  The 
design  spiral  of  developing  the  systems  should  be  stopped  to  successfully  spend 
the  time  on  getting  the  subsystems  to  function  together.  With  the  release  of  the 
Capability  Development  Document  the  System  Performance  Specifications  are 
updated  to  include  the  new  or  modified  requirements.  Any  additional 
environmental  constraints  are  addressed  at  this  time.  At  the  end  of  this  phase 
you  have  your  System  Requirements  Review.  (Defense  Acquisition  Guidebook, 
2005,  Chap.  4.3.3.3.1) 

c.  Functional  Requirements 

From  the  updated  System  Performance  Specification  you  develop 
System  Functional  Specifications  and  the  System  Verification  Plan.  As  you  do 
this  you  look  back  at  your  performance  specifications  and  perform  trade-offs 
between  subsystems.  Requirements  that  conflict  or  have  the  potential  for 
exceeding  cost  are  analyzed  and  changed  if  necessary.  Here  is  where  the 
integration  of  the  subsystems  begins.  Interfaces  between  the  subsystems  are 
identified  and  integration  requirements  are  developed.  The  System  Verification 
Plan  is  developed  and  demonstrates  how  each  requirement  will  be  verified.  As 
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the  requirements  are  added  and  modified  the  path  to  verification  is  recorded  in 
the  database  with  the  requirement.  This  phase  ends  with  the  System  Functional 
Review.  (Defense  Acquisition  Guidebook,  2005,  Chap.  4. 3. 3. 3.2) 

d.  Design  to  Requirements 

After  finalizing  your  functional  requirements  you  begin  to  create 
design  to  requirements.  This  set  of  specifications  is  what  will  be  used  to  perform 
detail  design  of  the  system.  The  Configuration  Item  Verification  Plan  is  created 
to  show  how  the  design  requirements  will  be  met.  This  phase  ends  with  the 
Preliminary  Design  Review.  (Defense  Acquisition  Guidebook,  2005,  Chap. 
4. 3. 3. 3. 3) 

e.  Build  to  Requirements 

After  finalizing  your  design  to  requirements  you  begin  to  create 
build  to  requirements.  This  set  of  specifications  is  what  will  be  used  to  perform 
actual  construction  of  the  system.  The  Inspection  Plan  is  created  to  show  how 
the  product  will  be  checked  against  the  design  and  build  to  documentation.  The 
last  review  in  the  System  Integration  phase  is  the  Critical  Design  Review. 
(Defense  Acquisition  Guidebook,  2005,  Chap.  4. 3. 3. 3.4) 

3.  Shipyard  Definition  of  Integration 

As  stated  earlier  in  this  thesis  is  the  idea  that  the  shipyard’s,  or 
shipbuilder’s,  concept  of  integration  is  different  than  the  Department  of  Defense’s 
definition.  This  is  because  the  two  groups  have  different  vantage  points  on  the 
process.  It  is  the  Department  of  Defense’s  job  to  explain  and  document  to  the 
shipbuilder  the  soldiers’  wants  and  needs.  The  formal  requirements  instantiate 
these  wants  and  needs.  Once  the  build  to  specifications  are  approved  and  the 
inspection  plan  is  created  the  Department  of  Defense  uses  those  documents  to 
govern  and  status  the  progress.  But  for  the  shipbuilder  only  the  integration 
planning  and  concepts  have  been  defined.  Integration  will  not  take  affect  until 
production  is  done. 

Going  back  to  the  example  used  in  Section  2  on  the  power  requirement 
we  can  explain  the  shipbuilder’s  point  of  view  on  integration  of  this  requirement. 
As  stated  earlier  the  Department  of  Defense  uses  the  definition  of  Systems 
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Integration  to  be  when  the  build  to  specifications  are  completed.  The  shipbuilder 
will  not  know  if  the  integration  effort  was  successful  until  the  ship  is  tested  during 
sea  trials.  Therefore  integration  is  not  complete  until  after  testing. 


Figure  6.  Basic  Vee  Model  (from  Forsberg,  Mooz,  and  Cotterman,  2000,  p. 

116) 

Forsberg,  Mooz,  and  Cotterman  in  “Visualizing  Project  Management” 
define  integration  as  “combining  entities  to  prove  performance  and  compatibly.” 
(p.115)  Proving  performance  and  compatibly  is  done  through  testing  and 
verification. 

Figure  6  is  taken  from  “Visualizing  Project  Management.”  The  downward 
side,  which  Forsberg,  Mooz,  and  Cotterman  call  “Decomposition  and  Definition” 
contains  essentially  the  same  steps  discussed  in  the  Department  of  Defense’s 
model  which  was  called  Systems  Integration.  The  upward  side  of  the  vee  is 
labeled  “Integration  and  Verification”  by  Forsberg,  Mooz,  and  Cotterman.  (p. 
115)  The  Department  of  Defense  calls  this  part  of  the  process  the  System 
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Demonstration  side.  An  important  point  here  is  that  the  Department  of  Defense 
and  Forsberg,  Mooz,  and  Cotterman  are  performing  the  same  tasks  in  their 
respective  models,  but  have  different  names  for  the  steps. 

Barker  (2000)  in  “Here  Be  Dragons,  An  Integration  Shopping  List”  defines 
integration  as  “a  complex  system  of  problems,  rather  than  a  single  complex 
problem.”  (p.  284)  The  Department  of  Defense  labels  Systems  Integration  as  the 
planning  stage  for  those  problems,  but  the  shipbuilder  sees  integration  as  the 
problems  to  be  solved  after  the  final  stages  of  testing  as  defined  by  the 
subsystem  tests. 

4.  Author’s  Synopsis  of  Systems  Integration  Definition 

Systems  integration  is  performed  to  verify  that  the  system  performs  as 
required  in  the  System  Performance  Specifications.  Testing  is  done  to  assure 
that  the  requirements  in  the  build  to  specifications  are  met,  but  the  system  is  not 
fully  integrated  until  the  performance  is  assured.  Because  there  are  so  many 
different  parts  that  pertain  to  just  one  area  of  performance,  systems  integration  is 
a  very  complicated  problem. 

System  integration  takes  people.  A  piece  of  software  can  be  written  to 
perform  the  task,  but  a  person  must  define  how  the  task  will  be  performed.  How 
the  pieces  fit  together  and  work  is  purely  a  human  task. 

The  key  to  systems  integration  is  not  just  answering  the  questions  you 
know  to  ask,  but  discovering  what  is  not  being  asked!  There  are  things  that  can 
be  done  to  ease  the  integration  of  complex  systems,  but  to  say  that  if  you  do  all 
of  these  things  integration  will  not  be  a  problem  is  impossible. 

It  is  in  everyone’s  best  interest  to  find  all  of  the  mismatches  before 
production  or  operation  begin.  As  everyone  knows,  fixing  a  design  issue  on 
paper  is  a  lot  easier  and  cheaper  than  when  the  system  has  been  built.  You  can 
argue  that  the  effort  isn’t  worth  the  trouble;  you  can  spend  lots  of  money  working 
integration  and  not  have  any  guarantee  that  the  integration  issues  have  been 
solved  as  mentioned  in  the  paragraph  above.  So  why  even  try?  The  reason  is 
this:  in  shipbuilding  real  prototypes  do  not  exist.  The  first  of  a  class  of  ships  will 
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be  used  in  service;  ships  are  too  expensive  to  build  and  then  discard  without 
being  put  into  service.  It  is  potential  cost  avoidance  in  other  programs,  but  it’s 
necessary  in  shipbuilding.  This  thesis  is  postulating  that  a  good  plan  needs  to  be 
established  during  the  requirements  definition  phase,  what  the  Department  of 
Defense  calls  “System  Integration”  to  facilitate  production  design  and 
construction.  One  the  plan  is  developed  and  implemented  it  should  be  revisited 
and  adjusted  with  the  idea  in  mind  to  continue  to  reach  towards  meeting  the 
performance  requirements  within  the  cost  and  schedule  constraints.  The  next 
chapter  fully  presents  the  reasons  why  systems  integration  is  more  necessary 
now  to  shipbuilding  than  it  ever  has  been  before. 
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II.  IMPORTANCE  OF  SYSTEM  INTEGRATION 


A.  INTRODUCTION 

When  making  a  change  in  the  way  business  is  done  it’s  best  to  start  with 
asking  if  a  change  is  needed.  This  paper  is  proposing  that  a  change  in  the 
shipbuilding  industry  is  necessary  to  develop  and  build  the  combat  ships  of  the 
future.  First  this  chapter  will  describe  the  cost  of  change  by  using  the  learning 
curve  theory.  Then  this  chapter  will  explore  where  we  are  in  history  by  comparing 
the  differences  in  shipbuilding  from  the  past  to  the  present  using  two  shipbuilding 
case  studies.  The  comparison  of  these  case  studies  will  demonstrate  the 
increasing  degree  of  complexity  with  integrating  a  first  of  class  ship  in  today’s 
world  versus  the  past.  Next  the  paper  will  discuss  a  successful  integrated 
system  and  a  failure  to  demonstrate  the  consequences  of  either  performing  or 
not  performing  systems  integration  correctly. 


B.  LEARNING  CURVE  THEORY 

The  reality  is  that  change  comes  with  a  price.  Learning  curve  theory 
shows  that  you  pay  for  change  upfront.  “As  experience  is  gained  with  the 
production  of  a  particular  product,  either  by  a  single  worker  or  by  an  industry  as  a 
whole,  the  production  becomes  more  efficient.”  (Nahmias,  2000,  p.  32) 
Shipbuilding  is  an  industry  that  uses  and  follows  the  trend  of  learning  curves. 
The  more  ships  we  build,  the  cheaper  we  can  build  them.  Shipbuilders  often  do 
not  plan  to  make  money  off  of  the  first  ship  of  the  class,  knowing  that  as  their 
workforce  becomes  more  experienced  with  the  hull  the  cost  of  production  will 
decrease.  If  you  make  a  change  the  learning  curve  goes  back  up,  and  the  hope 
is  that  you  end  up  below  the  original  learning  curve.  See  Figure  7  for  an  example 
of  what  a  learning  curve  may  look  like  after  implementing  a  major  change. 

The  same  can  be  said  about  the  design  process  for  building  ships.  Ships 
have  been  built  for  over  2000  years;  this  is  not  a  new  concept.  Shipyards  are 
filled  with  shipbuilders  that  understand  the  processes  they  use.  Shipbuilding  is 
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not  like  designing  and  building  anything  else  in  the  product  market.  Changing  a 
shipbuilding  process  runs  a  high  risk  of  being  more  expensive  due  to  the  fact  of 
all  the  other  changes  that  can  snowball  into  that  one  change.  It  is  with  this 
knowledge  and  understanding  that  this  paper  lobbies  for  change  during  the  detail 


design  process. 


Figure  7.  Learning  Curve  Example 

C.  USS  CONSTITUTION 
1.  Introduction 

The  USS  Constitution  is  the  oldest  commissioned  warship  in  the  U.S. 
Navy.  It  is  docked  in  Boston,  MA  and  is  over  200  years  old.  It  is  a  wooden  ship 
powered  with  sails.  See  Figure  8  for  a  picture  of  the  existing  ship. 
(http://www.ussconstitution.navy.mil) 
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Figure  8.  USS  Constitution  (from  http://www.ussconstitution.navy.mil) 


2.  Acquisition  Strategy 

At  the  end  of  the  Revolutionary  War  United  States  merchants  were 
unprotected  in  the  ocean  from  pirates.  During  the  war  the  country  had  a 
Continental  Navy,  but  the  cost  of  maintenance  of  even  one  frigate  was  too 
expensive  for  the  moneyless  nation.  The  last  frigate  was  sold  in  1785.  (Martin, 
2005,  p.  11)  Thomas  Jefferson,  then  Secretary  of  State  recommended  three 
solutions  to  the  pirate  problem: 

1.  Insure  cargos,  ransom  prisoners  regularly  at  a  fixed  rate,  and 
conduct  commerce  as  usual, 

2.  Buy  safe  conduct  with  tribute,  as  many  European  nations  did,  or 

3.  Fight,  (p.  12) 

Congress  decided  that  paying  ransoms  was  cheaper  than  creating  a  navy. 
But  eventually  the  overwhelming  activity  of  the  pirates  caused  Congress  to 
change  their  mind.  By  1794  Congress  passed  a  resolution  that  provided  a  naval 
force  sufficient  to  protect  American  merchantmen  from  pirates.  Congress 
appropriated  $600K  for  the  purchase  of  six  frigate  type  ships,  a  very  optimistic 
price,  (p.  13) 
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A  competition  was  not  held  for  the  design.  Joshua  Humphreys  was  an 
established  shipbuilder  in  Philadelphia  and  had  been  asked  for  quotes  while  the 
Secretary  of  Defense  was  gathering  information  on  how  much  it  would  cost  to 
build  the  frigates  and  he  quite  simply  wanted  the  job  and  went  after  it. 
Humphreys  designed  a  ship  that  was  fast,  powerful,  heavily  armored  and  could 
operate  independently  just  about  anywhere  in  the  world.  The  plans  for  the  ship 
were  located  on  one  sheet  of  paper  with  two  views.  See  Figure  9.  This  sheet 
and  the  list  of  materials  was  all  that  was  used  to  build  the  Navy’s  first  frigates, 
(pp.  24-25) 

To  build  the  six  ships  six  sites  were  chosen.  Congress  recognized  that 
using  one  or  two  shipyards  would  reduce  the  cost,  but  they  wanted  to  broaden 
the  country’s  shipbuilding  experience  and  hopefully  procure  the  ships  faster.  The 
shipyards  were  chosen  based  on  their  experience  during  the  Revolutionary  War 
and  politicians  and  businessmen’s  recommendations,  (p.  43) 


Shipyards  in  Portsmouth  (New  Hampshire),  Boston,  New  York, 
Philadelphia,  Baltimore,  and  Gosport  (Portsmouth),  Virginia  were  given  a 
contract  to  build  the  ships  three  weeks  after  President  Washington  signed  the 
bill.  Secretary  Knox  appointed  four  men  per  shipyard  to  oversee  the  construction 
of  the  frigates  for  the  government.  (Martin,  1 997,  p.  43) 

In  March  1796  an  Algerine  peace  treaty  was  signed.  The  act  that 
authorized  the  construction  of  the  ships  could  be  cancelled  since  the  pirates  were 
no  longer  a  threat,  but  President  Washington  and  Congress  decided  that  the  loss 
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of  work  for  all  the  men  involved  in  the  construction  of  the  ships  would  not  be  in 
the  best  public  interest,  so  it  was  decided  to  continue  with  the  original  contract 
but  to  build  three  ships  and  suspend  construction  on  the  other  three,  (p.  61) 

With  the  suspension  of  the  three  ships  material  for  those  ships  was  sent  to 
the  ships  remaining  under  construction.  Even  with  the  extra  material 
approximately  $100,000  of  extra  money  was  estimated  to  complete  the  three 
ships.  This  money  was  appropriated  March  1797,  an  hour  within  the  end  of 
Washington’s  term  for  president,  (p.  67) 

The  USS  United  States  was  the  first  ship  launched,  followed  by  the  USS 
Constellation.  The  USS  Constitution  was  being  built  in  Boston  and  was  launched 
last  in  October  1797.  Anyone  familiar  with  shipbuilding  knows  that  the  launching 
of  the  ship  does  not  mean  construction  is  finished.  Launching  of  the  USS 
Constitution  was  done  once  the  ship  was  “ship-shape,”  that  is  a  floatable  vessel, 
but  not  outfitted  for  use.  (p.  84) 

By  the  time  the  USS  Constitution  was  launched  the  United  States  was 
starting  to  see  “free  trade  upon  the  high  seas”  affected  by  the  “belligerents  in 
Europe,  Britain  and  France.”  Pirates  were  no  longer  the  main  concern,  (p.  89) 

In  January  1798  the  Secretary  of  War  asked  Congress  for  an  additional 
$400,000  to  finish  the  construction  of  the  ships  and  other  naval  matters,  (p.  89) 
The  USS  Constitution  was  finally  ready  for  sea  July  1798.  (p.  98) 

3.  Cost  and  Schedule 

It  took  over  four  years  to  build  the  USS  Constitution.  Initially  $115,000 
had  been  appropriated  to  construct  the  ship.  The  final  bill  was  $302,719.  That 
amounts  to  a  cost  overrun  of  260%.  (pp.  98-100) 

The  Secretary  of  War,  McHenry,  was  asked  to  explain  the  cost  overrun. 
He  listed  five  causes: 

1 .  Building  the  ships  in  different  places 

2.  Size  of  the  ships 

3.  Quantity  of  live  oak  used  in  construction 
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4. 


Rise  of  material  and  labor  costs 


5.  Certain  losses  and  contingences  (p.  100) 

The  choice  to  build  the  ships  at  different  yards  certainly  increased  the 
cost,  but  the  country  needed  the  ships  as  quickly  as  possible.  The  ships  were 
upgraded  to  “super  frigates”  from  the  normally  armed  frigates  of  standard 
construction.  Live  oak  was  used  in  lieu  of  white  oak,  which  proved  to  be  more 
difficult  to  procure.  Labor  and  material  costs  rose.  For  example  in  Philadelphia 
from  the  date  of  the  first  estimate  to  launch  labor  increased  by  40%.  Then  things 
just  happened,  like  a  fire  that  burned  about  fifty  tons  of  hemp  in  Boston,  (p.  100) 

McHenry  concluded  his  report  with  the  following  thought: 

The  great  delay  that  has  occurred  in  the  present  undertaking  must 
always  be  more  or  less  experienced,  when  heavy  ships  of  war  are 
required  to  be  suddenly  built,  and  the  Government  not  previously 
possessed  of  the  necessary  time  and  materials.  It  is  certainly  an 
unfit  time  to  look  for  these,  and  prepare  a  navy  yard,  when  the 
ships  are  required  for  actual  service.  .  .  (p.  101) 

McHenry’s  point  is  that  it  is  not  feasible  to  attempt  to  start  a  new 
shipbuilding  design  and  construction  contract  at  the  time  you  need  the  ships. 
Warships  require  a  massive  amount  of  planning  and  time.  But  this  is  bound  to 
happen  when  adequate  resources  are  not  available 

D.  DD(X) 

1.  Introduction 

The  DD(X)  is  the  newest  and  most  technically  advanced  shipbuilding 
program  untaken  by  the  U.S.  Navy  today.  It  is  designed  to  be  undetectable  by 
our  enemies  and  uses  electrical  drive  to  power  and  move  the  ship.  (“DD(X),” 
2005) 
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2.  Acquisition  Strategy 

DD(X)  was  first  conceptionalized  as  DD-21  under  the  Navy’s  vision  of 
“Forward.  .  .  From  the  Sea”  in  1994.  The  ship  was  intended  to  replace  the  DD 
963  and  FFG  7  Classes  of  Destroyer  and  Frigate  in  the  fleet  today.  (“DD-21 
Zumwalt,”  2000) 

The  Land-Attack  Destroyer  (DD-21)  is  the  first  surface  combatant 
founded  entirely  upon  post-Cold  War  thinking  and  strategic 
concepts.  Accordingly,  the  DD-21  design  concept  will  support  joint- 
service  requirements  in  littoral  regions.  Armed  with  an  array  of  land- 
attack  weapons,  DD-21  will  provide  sustained,  offensive, 
distributed,  and  precise  firepower  at  long  ranges  in  support  of 
forces  ashore.  With  state-of-the-art  information  technologies,  DD- 
21  will  operate  seamlessly  with  other  naval,  ground,  and  land- 
based  air  forces,  and  will  be  in  accordance  with  the  Navy's  evolving 
"Network-Centric  Warfare"  concept  of  operations  and  IT-21 
(Information  Technology  for  the  21st  Century)  architecture. 
(http://www.metsci.com) 

The  Mission  Need  Statement  (MNS)  was  released  June  1995.  (“DD-21 
Zumwalt.”  2000)  See  Figure  10  for  an  artistic  rendering  of  DD  21 . 


Figure  10.  DD  21  Artistic  Render  (from  “DD-21  Zumwalt,”  2000) 

The  DD  21  Program  passed  Milestone  I  January  1998  and  released  the 
formal  solicitation  in  March  1998.  DD  21  was  developed  under  the  1996 
Department  of  Defense  Acquisition  Model  (See  Figure  11).  The  first  ship  was  to 
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be  awarded  in  2004  and  the  Navy  planned  to  buy  32  ship  total  at  a  rate  of  3  per 
year.  See  Figure  12  for  a  view  of  the  technologies  planned  for  DD  21.  The  ship 
was  expected  to  cost  $750M  per  ship  in  FY96  dollars  by  the  fifth  constructed 
ship.  The  plan  was  for  two  teams  to  compete  for  the  design  and  build  of  the  DD 
21  Class  Ships,  but  both  shipyards  would  share  in  the  design  and  construction  of 
the  ships  themselves  with  the  loser  being  the  “follow’  shipyard.  Only  one 
Systems  Integrator  would  be  selected.  (“DD-21  Zumwalt,”  2000) 
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Figure  1 1 .  1996  Defense  Systems  Acquisition  Management  Process  (from 

Dillard,  2003,  p.  29) 
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DD  21  The  First  of  the  SC-21  Family 


REDUCED  SIGNATURES 
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Figure  12.  New  Technologies  of  DD  21  (from  “DD-21  Zumwalt,”  2000) 

Then  the  events  of  September  11,  2001  changed  all  of  the  military’s 
strategic  planning  for  the  future.  (“SeaPower21 2002)  In  November  2001  the 
Department  of  Defense  announced  that  the  DD  21  Program  had  been  revised 
and  would  now  be  known  as  DD(X).  With  the  new  program  name  the  acquisition 
management  cycle  was  updated  to  the  2000  version.  (See  Figure  13.)  The  major 
difference  between  the  original  cycle  and  the  new  one  was  the  addition  of  the 
System  Development  and  Demonstration  Phase  (SDD).  In  April  2002  the  Navy 
awarded  the  DD(X)  contract  to  Northrop  Grumman  and  Raytheon  with  General 
Dynamics  Bath  Iron  Works  as  the  follow  shipyard.  (“DD(X),”  2005)  Sea  Power 
21  was  released  later  that  year  and  DD(X)’s  mission  was  realigned  with  Sea 
Power  21.  See  Figure  14  for  Sea  Power  21  visual.  Admiral  Clark  wrote  of  the 
Sea  Power  21  vision: 

The  21st  century  sets  the  stage  for  tremendous  increases  in  naval 
precision,  reach,  and  connectivity,  ushering  in  a  new  era  of  joint 
operational  effectiveness.  Innovative  concepts  and  technologies  will 
integrate  sea,  land,  air,  space,  and  cyberspace  to  a  greater  extent 
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than  ever  before.  In  this  unified  battlespace,  the  sea  will  provide  a 
vast  maneuver  area  from  which  to  project  direct  and  decisive  power 
around  the  globe.  (“SeaPower21 2002) 
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Figure  13.  2000  Defense  Systems  Acquisition  Management  Process  (from 

Dillard,  2003,  p.  31) 
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SEA  POWER  21 


Sea  Shield 


Sea  Basing 


Sea  Strike 


Figure  14.  Sea  Power  21  (from  “SeaPower21 2002) 

The  nation’s  military  focused  on  terrorism,  reacting  to  protect  our 
homeland.  Admiral  Clark  described  the  dangers  as  follows: 

These  dangers  will  produce  frequent  crises,  often  with  little  warning 
of  timing,  size,  location,  or  intensity.  Associated  threats  will  be 
varied  and  deadly,  including  weapons  of  mass  destruction, 
conventional  warfare,  and  widespread  terrorism.  Future  enemies 
will  attempt  to  deny  us  access  to  critical  areas  of  the  world,  threaten 
vital  friends  and  interests  overseas,  and  even  try  to  conduct  further 
attacks  against  the  American  homeland.  These  threats  will  pose 
increasingly  complex  challenges  to  national  security  and  future 
warfighting.  (“SeaPower21,”  2002) 

In  the  past  the  nation  focused  on  certain  countries  and  regions  as  our 
enemies.  With  the  events  of  September  11th  we  needed  to  focus  more  broadly 
across  the  world.  (“SeaPower21 ,”  2002) 
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The  major  changes  to  DD(X)  included  a  reduction  of  weight.  DD  21  was 
expected  to  be  a  14,000  ton  ship  and  DD(X)  was  reduced  to  12,000  tons.  Crew 
size  for  DD  21  was  aimed  at  95,  but  DD(X)  increased  that  number.  The  radar 
system  was  changed  from  Multi-function  radar  to  Dual  Band  radar.  Thirty-two 
ships  were  expected  to  be  built  under  DD  21,  but  the  DD(X)  Program  reduced 
the  number  to  anywhere  from  eight  to  twelve.  First  ship  delivery  was  pushed 
back  from  2008  to  2011.  (“DD(X),”  2005)  See  Figure  15  for  a  summary  of  the 
new  technologies  on  DD(X). 
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Figure  1 5.  DD(X)  New  Technologies  (from  “DD(X),”  2005) 


In  February  2005  the  Navy  announced  a  change  in  its  acquisition  strategy 
for  DD(X).  This  was  due  to  the  FY  2006  President’s  budget  proposal  containing 
only  five  DD(X)’s.  Procurement  would  start  in  2006  and  one  ship  would  be  built 
each  year.  After  months  of  trying  to  estimate  the  cost  of  the  ship  into  the  amount 
the  Navy  had  appropriated  for  the  first  ship,  the  Navy  decided  to  try  to  save  some 
money  by  having  the  ships  built  at  one  shipyard  instead  of  two.  (“DD(X)  to  Go  to 
a  Single  Yard?,”  2005)  This  plan  was  rejected  in  April  by  Congress  due  to 
political  pressure  from  the  states  of  the  two  shipyards. 
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The  Senate  put  more  money  than  the  President’s  Budget  proposed  into 
the  DD(X)  Program  and  the  House  reduced  the  amount  of  money.  In  June  2005 
the  DD(X)  program  had  a  successful  06  level  Critical  Design  Review  (CDR.)  In 
November  2005  the  Pentagon  decided  to  allow  the  program  to  proceed  into 
detail  design  and  construction.  The  Navy  currently  plans  to  build  eight  ships. 
(Tortorano,  2005) 

3.  Schedule  and  Cost 

Initially  the  DD21  was  planned  to  be  delivered  in  2008,  taking  four  years  to 
construct  the  ship.  The  DD(X)  is  now  planned  to  be  delivered  in  2012,  taking  six 
years  to  construct.  Cost  for  the  fifth  DD  21  was  aimed  to  be  $750  M  in  FY  96 
dollars.  The  latest  estimate  is  over  $3.0  B  in  FY  2005  dollars.  (Tortorano,  2005) 

E.  USS  CONSTITUTION  VS.  DD(X) 

1.  Introduction 

The  problems  associated  with  acquisitioning  ships  have  not  changed 
much  through  the  years.  Both  ships  took  longer  and  cost  more  to  build  than 
originally  estimated.  The  mission  for  building  the  ships  changed  during  the 
acquisition.  Congress  decides  the  ship’s  mission  and  acquisition  strategy 
instead  of  the  Navy.  But  as  shown  in  Table  2  you  can  clearly  see  that  the 
development  of  US  Navy  ships  has  become  much  more  complicated. 

It  is  obvious  after  laying  out  these  facts  that  the  DD(X)  is  a  much  more 
complex  ship.  A  minimum  amount  of  integration  was  needed  on  the  USS 
Constitution.  The  design  was  completed  by  one  person  and  was  done  in  a 
reasonably  short  period  of  time.  The  government  oversight  was  minimal  with 
only  four  men  overseeing  the  ship  construction.  But  look  at  the  crew  size;  twice 
as  many  sailors  were  needed  to  operate  the  Constitution.  Technology  has  done 
a  lot  for  us  in  automation  and  less  manual  work,  but  the  complexity  of  having 
machines  and  software  perform  the  tasks  require  more  planning  in  the  design. 
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USS  CONSTITUTION 

DD(X) 

No.  of  designers 

1 

2000 

Years  to  develop  design 

1 

10+ 

Amt  of  government  oversight 

4 

200 

Crew  size 

245 

114 

Number  of  construction  drawings 

1 

3000+ 

Table  2:  USS  Constitution  vs.  DD(X)  (after  Martin,  1997  and  “DD(X),”  2005) 

All  of  these  items  add  up  to  needing  to  perform  more  integration.  As  more 
people  are  involved,  the  design  gets  more  complicated.  As  less  people  are  used 
to  operate  the  ship  there  becomes  more  interface  problems  by  having  more 
automated  systems.  Sean  Barker’s  (2000)  definition  of  integration  states: 
“Integration  is  a  complex  system  of  problems,  rather  than  a  single  complex 
problem.  The  first  difficulty  with  any  integration  project  is  to  get  a  common 
understanding  of  which  problems  are  actually  being  addressed  by  the  project  and 
which  are  not.”  (284).  Now  we  will  analyze  one  system  on  the  USS  Constitution 
and  the  DD(X)  to  compare  the  complexity  of  the  design  and  manpower  for 
operability  of  the  system. 

2.  Anchor  Handling 

All  ships  have  an  anchor  of  some  sort.  They  allow  the  ship  to  stay  in  one 
place.  The  anchor  must  be  heavy  enough  to  keep  the  ship  from  moving.  The 
USS  Constitution  carried  six  anchors  and  required  as  many  as  180  men  on 
anchor  duty.  The  main  bower  anchor  on  the  USS  Constitution  weighed  5304  lbs. 
(See  Figure  16)  A  capstan  (See  Figure  17)  is  used  to  raise  and  lower  the 
anchors.  Twelve  long  poles  are  inserted  in  the  capstan  and  ropes  are  used  as  a 
pulley  as  the  men  push  the  anchor  up  or  down  by  walking  around  the  capstan. 
See  Figure  18  of  a  picture  of  the  main  bower  anchor  detail.  It  required  more  than 
150  men  to  raise  this  anchor.  (“Capstans  and  Anchors,”  2005) 
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Figure  16.  Main  Bower  Anchor  Dockside  (from  “Capstans  and  Anchors,”  2005) 


Figure  17.  Capstan  on  Gun  Deck  (from  “Capstans  and  Anchors,”  2005) 
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Figure  18.  USS  Constitution  Anchor  Detail  (from  Martin,  2005,  p.  97) 

There  is  little  doubt  that  the  system  used  to  raise  and  lower  the  anchor  on 
the  USS  Constitution  is  a  design  that  worked  and  could  be  used  today,  but  it  is 
both  labor  and  time  intensive.  The  U.S.  Navy  is  continually  trying  to  lower  what 
they  term  “life  cycle  cost;”  that  is  the  cost  associated  with  operating  a  ship. 
Sailors  are  the  most  expensive  part  of  maintaining  a  ship;  therefore  designs  that 
reduce  the  amount  of  sailors  to  operate  a  ship  are  highly  efficient  for  the  U.S. 
Navy. 

DD(X)  has  one  anchor.  The  need  for  multiple  anchors  diminished  with  the 
addition  of  engines  on  ships.  The  DD(X)  anchor  system  is  designed  as  a  module 
system.  (See  Figure  19)  This  means  that  the  whole  system  can  be  installed  in 
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one  piece  and  tested  before  it  is  installed.  It  is  operated  by  software  and  requires 
one  sailor  to  operate  the  anchor  control  system  only  when  the  anchor  needs  to 
be  raised  or  lowered.  It  is  also  designed  to  be  completely  below  the  deck. 
Mechanical  powered  capstans  are  currently  used  on  U.S.  Navy  ships  to  operate 
anchors,  but  the  requirement  to  be  hidden  from  the  enemy  from  radar  prevents 
the  use  of  traditional  capstans  on  the  deck.  This  is  just  one  example  of  how  the 
DD(X)  is  changing  traditional  ship  design  and  operation.  (“DD(X),”  2005) 


Figure  1 9.  DD(X)  Module  Anchor  (from  “DD(X),”  2005) 


The  comparison  of  the  anchor  system  between  the  two  ships 
demonstrates  how  the  design  has  gotten  much  more  complex  for  essentially  the 
same  task.  With  the  complexity  comes  additional  benefits,  most  noticeable  the 
number  of  people  it  takes  to  operate  the  anchor.  On  the  USS  Constitution  up  to 
180  men  were  required  to  raise  or  lower  the  anchor.  Only  one  is  needed  on  the 
DD(X)  and  it’s  not  even  a  full-time  job.  With  the  reduction  of  personnel  comes 
additional  design  criteria  and  interfaces  with  other  operating  systems. 
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F.  CASE  STUDIES  OF  SYSTEMS  INTEGRATION:  SUCCESS  &  FAILURE 

The  proof  that  a  newly  developed  system  is  integrated  occurs  after 
assembly  and  into  operation.  These  two  cases  studies  describe  the  success  and 
failure  of  two  complex  systems. 

1.  Failure:  Apollo  13 

Apollo  13  launched  on  April  11,  1970  and  was  to  be  the  third  manned 
mission  to  land  on  the  surface  of  the  moon.  On  the  second  day  of  the  trip  from 
the  earth  to  the  moon,  the  three  astronauts  heard  and  felt  a  large  bang  when 
they  stirred  the  oxygen  tanks.  During  the  next  few  minutes,  the  crew  and  the 
ground  controllers  determined  that  two  of  the  three  fuel  cells  in  the  Command 
Service  Module  had  gone  dead,  and  both  oxygen  tanks  were  rapidly  losing 
pressure.  (Howard,  1995)  See  Figure  20  for  the  damaged  Apollo  spacecraft. 


Figure  20.  Apollo  13  Damaged  Spacecraft  (from  “The  Apollo  13  Accident,” 

2005) 

The  engineers  at  NASA  did  a  fantastic  job  in  bringing  the  crew  safely 
home  by  recalculating  trajectories  and  burn  durations,  devising  new  navigation 
and  flight  control  procedures,  and  estimating  how  long  critical  supplies  would 
last.  Working  with  the  crew,  they  developed  ways  to  use  the  Lunar  Module  as  a 
"life  raft,"  using  its  environmental  support  systems,  electrical  batteries,  and 
engines,  to  substitute  for  the  lost  capability  in  the  Command  Module.  Four  days 
later  the  crew  returned  safely  to  Earth,  but  they  had  been  forced  to  abort  their 
mission  of  landing  on  the  moon.  (Howard,  1995) 
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After  two  months  of  study,  the  problem  was  determined  to  have  been  a 
rupture  of  oxygen  tank  Number  2  in  the  Service  Module.  The  cause,  as  astronaut 
James  Lovell  later  wrote,  was  the  result  of  an  "accumulation  of  human  errors  and 
technical  anomalies,"  not  a  single  cause.  (“The  Apollo  13  Accident,”  2005) 

The  oxygen  tanks  had  originally  been  designed  to  run  off  the  28  volt  DC 
power  of  the  Command  and  Service  Modules.  However,  the  tanks  were  designed 
to  also  run  off  the  65  volt  DC  ground  power  at  the  Kennedy  Space  Center.  All 
components  were  upgraded  to  accept  65  volts  except  the  heater  thermostatic 
switches,  which  were  overlooked.  These  switches  were  designed  to  open  and 
turn  off  the  heater  when  the  tank  temperature  reached  80  degrees  F.  (“The 
Apollo  13,”  2000) 

The  Number  2  oxygen  tank  used  in  Apollo  13  had  been  previously 
installed  in  Apollo  10.  It  had  been  removed  for  modification,  and  in  the  process 
had  been  dropped  about  2  inches  causing  noticeable  damage.  It  was  repaired 
and  installed  in  Apollo  13.  Tests  indicated  the  tank  was  operating  properly,  but 
ground  crews  experienced  significant  difficulty  draining  it.  But  all  cognizant 
individuals,  including  the  flight  crew,  decided  it  was  not  a  serious  problem. 
(“Apollo  13,”  2000) 

During  pre-flight  testing,  tank  Number  2  showed  irregularities  and  would 
not  empty  correctly.  It  was  decided  to  use  the  heater  to  "boil  off"  the  excess 
oxygen,  requiring  8  hours  of  65  volt  DC  power.  Because  it  had  not  been 
upgraded  to  work  with  65  volt  DC  power  this  may  have  damaged  the 
thermostatically  controlled  switches  on  the  heater.  Prior  to  launch,  the 
temperature  of  the  whole  assembly  rose  to  over  1000  degrees  F,  causing  severe 
damage  to  the  protective  Teflon  insulation  on  the  electrical  wires  to  the  power 
fans  in  the  tank.  (“Apollo  13,”  2000) 

When  the  power  fan  activated,  56  hours  into  the  mission,  the  exposed  fan 
wires  shorted  and  the  Teflon  insulation  caught  fire.  A  superabundance  of  pure 
oxygen  fed  the  fire,  and  the  pressure  rose.  One  oxygen  tank  burst,  the  other 
ruptured,  and  the  side  of  the  spacecraft  was  blown  out.  (“Apollo  13,”  2000) 
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NASA's  investigation  of  this  accident  found  no  fundamental  flaws  in  the 
Apollo  design  concept,  but  it  did  reveal  that  they  needed  to  do  a  better  job  of 
system  integration.  They  needed  to  improve  their  procedures  for  design  review, 
integration  of  modifications,  and  treatment  of  anomalous  test  data.  With  proper 
interfaces  developed  and  used  during  the  design  the  accident  could  have  been 
avoided.  (“Apollo  13,”  2000) 

2.  Success:  Boeing  777 

In  October  1990,  Boeing’s  777  program  was  launched  when  United 
Airlines  agreed  to  order  the  aircraft.  In  1995  Boeing  received  the  Collier  Trophy 
for  designing,  manufacturing,  and  introducing  into  service  the  world’s  most 
advance  commercial  jet.  This  was  also  the  year  that  United  Airlines  flew  their 
first  777  for  commercial  service.  Since  first  hitting  the  market  in  1995  Boeing  has 
delivered  over  4000  777  airplanes.  The  success  of  the  aircraft  is  shown  in  its 
safety  record  and  number  of  sales.  (“Boeing  777  Program  Information,”  2005) 
See  Figure  21  for  an  in-flight  view  of  the  777. 


Figure  21.  Boeing  111  (from  “Boeing  111  Program  Information,”  2005) 
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Boeing  attributes  its  success  of  the  design  and  manufacture  of  the  777  to 
several  key  things  that  they  did  differently  from  any  other  airplane  development 
they  had  performed  before.  (“Boeing  777  Program  Information,”  2005) 

a.  Design-Build  Teams 

Conduit,  the  program  manager  of  the  program,  was  quoted  as 
saying:  “If  you  go  back  to  the  earlier  planes  that  Boeing  built,  the  factory  was  on 
the  bottom  floor,  and  Engineering  was  on  the  second  floor.  Both  Manufacturing 
and  Engineering  went  back  and  forth.  The  entire  Design  Department  was  within 
50  feet  of  each  other.”  (Sabbagh,  1995,  p.  68)  Boeing  had  ten  thousand  people 
working  on  the  design  of  the  777.  That  made  it  impossible  for  everyone  to  be 
within  50  feet  of  each  other.  The  Design-Build  Teams  were  designed  to  allow 
“Manufacturing,  Tooling,  Planning,  Engineering,  Finance,  and  Material”  to  work 
together  on  the  design  of  specific  parts  of  the  aircraft,  (p.  69) 

The  teams  met  twice  a  week  for  two  hours  at  a  time.  There  were 
several  logistic  problems  with  this  approach.  First,  people  were  members  of 
more  than  one  team,  so  the  schedules  could  not  overlap.  Some  teams  had 
members  across  the  country,  so  video  teleconferencing  was  used.  Third  was 
finding  a  place  to  hold  the  meeting.  The  teams  used  an  agenda  and  kept  to  the 
items  on  the  agenda  and  careful  notes  were  taken  of  the  meetings.  Originally 
Boeing  had  planned  for  80  Design-Build  Teams  and  ended  up  with  250  Design- 
Build  Teams,  (p.  70) 

The  Design-Build  Teams  enabled  Boeing  to  do  three  things: 

•  Get  it  closer  to  right  the  first  time  before  it  was  manufactured 

•  Get  it  closer  to  right  before  it  was  tested 

•  Test  more  efficiently  (p.  70) 

b.  On  Site  Representation  of  Customers 

The  airline  customers  were  brought  into  the  Design-Build  Teams  if 
there  was  a  specific  issue  they  were  interested  in.  One  example  is  the  fueling 
panel.  United  and  the  other  airlines  had  fueling  stands  that  only  reached  a 
certain  height.  Boeing  did  not  consider  this  in  their  design.  So  Boeing  moved 
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the  fuel  panel  closer  to  the  ground.  “I  don’t  know  what  would  have  happened  if 
the  airplane  showed  up  at  our  stations  and  nobody  could  reach  the  fuel  panel- 
that  would  have  been  very  embarrassing.”  (p.  77)  By  including  the  customer,  or 
the  user,  Boeing  managed  to  avoid  design  decisions  that  did  not  include  the 
customer’s  needs. 

c.  3-D  CAD  (CATIA) 

CATIA  was  used  to  model  every  piece  of  the  aircraft  before  it  was 
built.  This  allowed  a  computer  mock-up  of  the  airplane  to  check  for  interferences 
between  different  parts  of  the  design.  “Boeing’s  decision  to  use  CATIA  in 
conjunction  with  a  team  concept  emerged  primarily  as  a  means  of  cutting  costs 
after  analysis  revealed  that  the  predominant  cost  drivers  were  rework  on  the 
factory  floor  and  down-stream  changes.”  (Battershell,  1995,  217)  “Every  few 
weeks  during  the  main  CATIA  design  phase,  a  halt  was  called  to  all  design 
activity,  a  design  freeze.  When  this  happened,  everybody  went  into  the  system 
and  looked  for  problems  that  had  arisen  because  of  the  interfaces  between  one 
system  or  set  of  parts  and  another.”  (Sabbagh,  1995,  p.  75)  By  bringing  a  halt  to 
the  design  activity  the  interferences  can  be  addressed  one  by  one,  not  by  order 
of  precedent,  but  by  which  system  needs  the  space.  This  allows  the  best  design 
to  be  utilized,  instead  of  a  design  that  is  just  doable.  In  the  past,  “engineers  were 
still  designing  when  manufacturing  began,  and  they  kept  making  changes  as 
problems  subsequently  came  to  light  on  the  factory  floor,  on  the  flight  line,  and 
even  in  the  customer’s  hands  after  the  plane  was  delivered.”  (Battershell  217) 

d.  Simulated  Testing  of  Systems  Before  Installation 

“New  laboratory  facilities  enabled  the  various  airplane  systems  to 
be  tested  together  as  a  single  integrated  entity  in  simulated  flight  conditions  -- 
before  the  first  jetliner  ever  took  to  the  air.”  (“Boeing  777  Program  Information,” 
2005)  Because  of  the  new  systems  used  on  this  aircraft  Boeing  wanted  the 
assurance  that  not  only  would  the  systems  work,  but  that  they  would  work 
together.  This  was  done  by  simulating  the  conditions  in  the  aircraft  in  a 
laboratory  setting.  Although  this  kind  of  testing  does  not  reduce  all  interface 
problems,  it  does  reduce  the  number  of  errors  that  would  otherwise  put  the  test 
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team  and  aircraft  at  risk  during  flight  testing.  By  testing  the  systems  together 
before  assembly  on  the  aircraft,  changes  can  be  made  that  otherwise  would  be 
costly  if  the  equipment  was  already  installed.  (“Boeing  777  Program 
Information,”  2005) 

The  combination  of  these  four  aspects  of  the  design  and  test  phase 
of  the  777  program  reduced  the  number  of  modifications  that  in  the  past  would 
have  been  made  during  manufacturing  or  at  or  after  delivery.  Just  one  of  those 
design  decisions  that  were  made  early  in  the  design  cycle  could  have  brought 
failure  to  the  entire  program.  Integration  and  design  problems  were  fixed  at  the 
earliest  possible  time.  The  success  of  this  program  is  shown  in  the  fact  that  the 
airplane  made  delivery  on  time  and  the  airliners  have  been  able  to  use  the  777 
for  10  years  now  and  are  still  ordering  more.  For  this  reason  the  Boeing  777  is  a 
successfully  integrated  product. 
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III.  INTEGRATION  CONCEPTS  &  IDEAS 


A.  INTRODUCTION 

To  summarize,  at  this  point  we  have  discussed  what  integration  is,  why 
integration  is  more  important  now  than  it  has  been  in  the  past  for  shipbuilding, 
and  how  integration  can  cause  the  failure  or  success  of  a  program.  Based  on 
this  information  and  my  experience  as  a  shipbuilder,  I  present  my  concepts  and 
ideas  of  things  to  do  to  reduce  shipbuilding  integration  problems. 

B.  CONCEPTS  AND  IDEAS 

1.  Integrated  Product  Teams 

This  concept  was  developed  by  the  Department  of  Defense  from  the  idea 

of  Boeing’s  Design-Build  Teams.  I  have  seen  the  use  of  the  title  in  my  industry, 
but  not  the  concept.  Currently  Integrated  Product  Teams  are  just  the  name  of 
the  organization  of  a  certain  engineering  specialty.  As  example  of  this  is  a 
Propulsion  Integrated  Product  Team  whose  members  include  only  propulsion 
engineers.  Integrated  Product  Teams  should  include  members  from  every  part 
of  the  design,  manufacture,  and  test  that  have  anything  to  do  with  the  specified 
product.  As  a  general  rule  of  thumb  I  recommend  the  following  team  members 
for  any  system  being  developed  for  a  ship: 

•  Design  engineer 

•  Signature  engineer 

•  Weight  engineer 

•  Software  engineer 

•  System  engineer 

•  Test  engineer 

•  Arrangement  designer 

•  Material  buyer 

•  Craft  discipline 

•  Quality  inspector 

•  Customer 
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•  Planner 

•  Cost  engineer 

Every  Integrated  Product  may  not  need  every  member  of  this  team  and  some  will 
require  more.  You  must  be  flexible  to  assure  that  the  right  people  are  involved. 

To  correctly  develop  Integrated  Product  Teams  the  ship  should  be  broken 
down  into  the  major  systems  that  require  the  involvement  of  the  different 
disciplines.  This  can  be  done  based  on  the  current  management  structure  of 
engineering  disciplines  or  craft  management,  but  should  reflect  systems  or 
products  of  the  ship  instead  of  stovepipes  in  the  organization.  I  propose  the 
following  Integrated  Product  Teams  as  a  minimum: 

•  Naval  Architecture:  The  hull  form  needs  to  include  ship  performance 

in  the  water,  but  also  ship  performance  for  radar  signature  control. 

•  Power:  This  includes  propulsion  and  ship’s  services. 

•  Combat  Systems:  Combat  Systems  are  a  set  of  complicated  systems 

usually  designed  by  a  single  source  vendor  for  the  shipyard.  The 
interface  of  these  systems  requires  careful  planning  for 
arrangement  and  weight  control. 

•  Machinery:  Machinery  includes  all  of  the  equipment  required  to 

provide  ship  services  to  the  crew  and  its  associated  piping. 
Steering  gears,  pumps,  and  HVAC  are  just  a  few  examples. 

Most  of  these  Integrated  Product  Teams  will  need  to  be  further  broken 
down  into  sub-teams  of  the  major  Integrated  Product  Team.  It  then  becomes  the 
responsibility  of  the  major  team  to  make  decisions  on  interfaces  between  the 
teams  and  the  sub-teams  design  the  actual  product.  Empower  the  sub-teams  to 
design  to  performance  and  cost  constraints  by  providing  them  goals  or  budgets. 

If  used  correctly  Cross  Product  Teams  should  not  be  necessary,  because 
they  will  be  members  of  each  of  the  Integrated  Product  Teams.  It  is  a  good  idea 
to  still  allow  a  functional  management  group  to  provide  training  and  mentoring  to 
the  employees  involved  in  the  Integrated  Product  Teams  by  specialty. 

When  the  teams  are  formed  and  members  are  chosen,  give  everyone  a 
copy  of  each  teams’  organization  chart.  Ensure  that  all  employees  understand 
their  role  and  responsibility  and  who  they  report  to. 
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To  use  the  Integrated  Product  Team  approach  you  need  to  provide  the 
necessary  equipment  and  space  to  hold  meetings.  Have  conference  rooms 
available  using  a  first  come,  first  serve  method  for  reservations  with  projectors, 
smart  boards,  video  teleconferencing,  and  computers  in  the  conference  rooms. 
Encourage  the  use  of  video  teleconferencing  to  reduce  travel  costs  and 
employee  stress.  Send  employees  to  training  on  how  to  hold  a  meeting  and 
require  meeting  notes  and  action  items  to  be  recorded  and  tracked.  Provide 
special  training  to  employees  working  in  Integrated  Product  Teams  that  use 
video  teleconferencing. 

2.  Data  Collection  and  Transfer 

After  you  decide  how  the  organization  will  be  set-up,  you  should  then 
determine  how  information  will  be  stored  and  transferred.  These  days  most 
communication  of  ideas  and  drawings  are  done  electronically.  At  the  beginning 
of  the  program  you  need  to  decide  which  programs  will  be  used  and  ensure  that 
when  and  where  they  interact  with  other  programs  the  data  can  be  transferred 
and  do  not  change  it.  For  example,  say  the  whole  ship  model  will  use  a  3-D  CAD 
program  such  as  CATIA.  The  structural  engineers  will  need  to  perform 
calculations  of  the  ship  stresses.  If  you  plan  ahead  and  know  before  you  buy  the 
software  to  perform  the  stress  analysis  if  it  will  use  a  file  exported  from  CATIA  the 

structural  engineers  will  not  need  to  re-model  the  ship  to  perform  their  analysis. 
This  can  save  cost  and  time,  but  also  accuracy  as  the  design  matures  and  new 
analyzes  are  performed. 

3.  Interface  Definition 

Within  the  Integrated  Product  Teams  the  team  members  will  realize  that  it 
is  impossible  to  get  everyone  involved  with  the  design  that  they  need.  The 
HVAC  system,  for  example,  would  need  inputs  from  anyone  that  had  a  piece  of 
equipment  that  required  cooling.  That  size  of  team  would  be  impossible  to 
manage.  As  a  management  technique  the  teams  should  identify  their  interfaces. 
That  is,  which  systems  they  need  information  from  and  which  ones  need 
information  from  them.  By  doing  this  at  the  beginning,  once  the  design  begins 
they  will  know  and  understand  who  they  need  to  exchange  data  with. 
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4.  Standardize  Everything 

All  forms,  presentations,  reports,  and  tools  need  to  be  standardized.  This 
allows  the  integrated  product  teams  to  focus  on  designing  the  product,  instead  of 
how  to  format  a  report.  These  items  should  be  as  easy  to  use  as  possible  and 
present  a  clean,  professional  look.  For  example,  if  you  need  to  access  risk  on 
your  program,  everyone  should  use  the  same  tool  and  parameters  to  accurately 
rank  a  risk  item.  The  output  should  be  the  same  so  that  when  the  customer 
looks  at  the  data  they  do  not  have  to  relearn  how  to  read  the  information. 

5.  Modeling 

Do  as  much  modeling  using  computer  programs  as  you  can.  The  earlier 
that  design  flaws  can  be  caught  in  the  design  cycle,  the  cheaper  they  are  to 
change.  All  of  the  problems  that  will  be  encountered  in  production  can  not  be 
caught  by  computer  modeling,  but  the  ones  that  can  be  caught  earlier  will  save 
you  time  and  money  for  use  on  those  items  that  will  be  missed. 

In  setting  up  your  process  for  modeling  determine  how  interferences  will 
be  resolved.  By  freezing  the  design  for  a  week  or  two,  all  the  integrated  product 
teams  can  focus  on  clearing  interferences,  one  by  one,  the  most  optimal  way 
possible.  If  the  design  is  not  frozen,  the  push  will  be  on  finishing  the  design  and 
the  interference  will  be  resolved  the  easiest  way  possible  at  the  time  by  the 
designer  instead  of  utilizing  the  team  and  finding  the  best  way. 

6.  Testing 

There  is  so  much  cost  involved  with  testing  that  if  you  can  simulate  a  test 
on  the  computer  first  then  you  should  do  it.  By  doing  this,  you  reduce  the 
number  of  things  that  can  go  wrong  with  the  test  when  you  perform  the  physical 
test.  But  do  not  make  the  mistake  of  substituting  simulation  with  physical  testing. 
Just  like  with  modeling,  the  computer  environment  can  help  with  identifying 
potential  problems,  but  a  computer  simulation  can  not  take  in  all  of  the  variables 
that  occur  in  real  life. 

Test  all  the  systems  and  their  interactions  before  you  install  the  equipment 
on  the  ship.  You  may  not  be  able  to  completely  simulate  the  shipboard 

environment,  but  if  you  can  work  out  the  majority  of  the  bugs  in  the  laboratory 
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instead  of  aboard  ship  you  will  not  impact  your  ship  construction  schedule  and 
the  environment  will  be  easier  and  less  costly  to  work  in. 

7.  Configuration  Management 

Establish  a  good  configuration  management  process  from  the  beginning  of 
the  program.  Make  sure  that  all  meetings,  drawings,  reports,  are  documented 
and  under  some  form  of  configuration  control.  As  the  design  matures  tighten  up 
the  configuration  control,  but  do  not  operate  a  single  day  on  your  program 
without  it.  You  must  be  able  to  accurately  demonstrate  the  reason  for  every 
design  decision  made  for  your  customer  or  if  you  have  a  failure  once  the  system 
is  operational.  You  should  plan  how  many  drawings  you  will  have,  not  just 
number  them  as  they  are  developed.  Otherwise  the  number  of  drawings  will 
spiral  out  of  control  and  will  become  hard  to  manage.  Change  to  the  design 
needs  to  be  managed  to  assure  all  parties  affected  are  aware  of  the  change  and 
its  impact  to  their  design. 

8.  Anticipate  the  Unknown-Unknowns 

There  will  be  problems  that  no  one  ever  thought  about  until  they  see  the 
system  operating  right  in  front  of  them.  Realize  that  this  will  happen  and  plan  for 
it.  You  will  not  be  able  to  solve  the  problem  if  you  do  not  know  what  it  is,  but  you 
will  be  able  to  position  the  team  to  anticipate  these  types  of  problems  and  react 
quickly  and  smartly  when  they  occur. 

C.  SUMMARY 

By  following  these  eight  steps  you  will  have  prepared  the  ship  for  total 
integration.  Unfortunately  there  is  nothing  that  can  be  done  to  assure  success, 
but  the  omission  of  one  thing  can  cause  failure.  “The  weakest  link  will  cause 
your  program  to  fail.”  (Marvel,  2004) 

This  paper  has  defined  what  systems  integration  means  to  both  the 
customer  and  the  contractor,  the  reasons  that  systems  integration  is  more 
important  in  today’s  environment  than  the  earlier  years  of  combat  shipbuilding, 
what  happens  when  systems  integration  is  done  correctly  and  not,  and  finally, 
concepts  and  ideas  gathered  from  research  and  experience  to  help  ensure  that  a 
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newly  developed  combat  shipbuilding  program  will  not  fail  due  to  a  systems 
integration  mistake.  Systems  integration  is  the  single  most  difficult  part  of 
designing  a  system  because  until  you  use  the  system  it  is  very  hard  to  determine 
what  you  are  not  considering  or  leaving  out  of  the  design.  A  combat  ship 
operates  as  a  home  for  the  sailors,  the  soldiers  it  carries,  storage  of  equipment,  a 
war-fighting  machine,  and  so  much  more.  A  combat  ship  contains  so  many 
different  systems  that  must  be  designed  to  work  together  that  proper  systems 
integration  is  critical  for  success.  Only  by  setting  up  the  design  teams  to  openly 
communicate  with  the  builders,  testers,  and  users  of  the  system  will  integration 
occur  as  needed  to  succeed.  Systems  integration  requires  people  to  be  in 
contact  to  design  the  systems  to  interact  properly. 
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